Can one of the admins verify this patch?

Why do you have to extends AbstractEto? IMHO this seems like map struct can not deal properly with generics. Is my guess correct?

Did you fork a state that was not working? The compile error in travis looks like it is not related to map-struct. I think this is a compiler error I caused some time ago (by not following our guideline to use PRs) that has been fixed right after. You should merge the original oasp4j repo back into your PR clone repo.

Why do you have to extends AbstractEto? IMHO this seems like map struct can not deal properly with generics. Is my guess correct?

Right - somewhere along traversing the type hierarchy, the type bounds were lost - I still need to create an example that is complex enough to reproduce the issue for the MapStruct issue-tracker (my first attempts with just an abstract super class that binds the type-variable in the generic interface wasn't enough, as it worked in that case). But I'm sure it's something that can be fixed. 😉

Did you fork a state that was not working? The compile error in travis looks like it is not related to map-struct. I think this is a compiler error I caused some time ago (by not following our guideline to use PRs) that has been fixed right after. You should merge the original oasp4j repo back into your PR clone repo.

Locally, it worked and I was able to start the application... I've rebased my commit to the latest head now.

I think our test-coverage is still poor, but your diff does not contain a solution for the modification counter (optimistic locking) that we solved for dozer and orika.
https://github.com/oasp/oasp4j/blob/develop/oasp4j-samples/oasp4j-sample-core/src/main/resources/config/app/common/dozer-mapping.xml#L45

https://github.com/oasp/oasp4j/blob/develop/oasp4j-modules/oasp4j-beanmapping/src/main/java/io/oasp/module/beanmapping/common/impl/orika/CustomMapperEto.java

But I'm sure it's something that can be fixed.

you should use an established libarary for that instead of solving this by hand. Resolving type variables and determining the actual type of a getter is extremely tricky since java 1.5. Most solutions out there including hibernate and spring do it wrong and are buggy. You might create a fix for this particular case but then might still contain bugs elsewhere.
Try classmate, guava or mmm-util-core that all solve the problem properly.

http://m-m-m.sourceforge.net/apidocs/net/sf/mmm/util/reflect/api/GenericType.html

Can one of the admins verify this patch?

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}